Scenario #9047: Re Synchronizing a User Subject with a Different Organization Moves It to That Organization

The sync program re-synchronizes an already existing USER subject with the same UUID and name, but a different explicit organization, e.g. after the user moved to another organization in Keycloak. The idempotent PUT updates the organization in place and returns 200 OK; the UUID and the name remain unchanged. For GROUP subjects the organization is bound to the group-name prefix, so it can only change together with a matching rename.

Properties

Required

• SubjectSync: bob@example.com from 9040: A Global Admin Can Synchronize a User Subject with an Explicit Organization

Given

name	value
subjectUuid	239a0001-0000-0000-0000-000000000001
subjectName	bob@example.com
organization	acme
subjectType	USER

Synchronize the subject via HTTP PUT

HTTP PUT "/api/rbac/subjects/239a0001-0000-0000-0000-000000000001" // SubjectSync: bob@example.com \
  -H "Authorization: Bearer $HSADMINNG_JWT_BEARER" \
  `# {` \
  `#   "sub" : "uuid<hsh-alex_superuser>"` \
  `# }` \
  <<EOF
{
  "name" : "bob@example.com",
  "organization" : "acme",
  "type" : "USER"
}
EOF
=> status: 200 OK 

The stored subject carries the expected organization

HTTP GET "/api/rbac/subjects/239a0001-0000-0000-0000-000000000001" // SubjectSync: bob@example.com \
  -H "Authorization: Bearer $HSADMINNG_JWT_BEARER" \
  `# {` \
  `#   "sub" : "uuid<hsh-alex_superuser>"` \
  `# }`
=> status: 200 OK 
{
  "uuid" : "239a0001-0000-0000-0000-000000000001", // SubjectSync: bob@example.com
  "name" : "bob@example.com",
  "organization" : "acme",
  "type" : "USER"
}

---

generated on 2026-08-10 04:34:39 for branch HEAD